Общий курс · осенний семестр · занятие 6 из 15

UML, часть 1: нотация и структура системы

О чём эта тема: Единый графический язык проектирования — UML: зачем он нужен, из каких элементов состоит его нотация и как читать три диаграммы «статики»: вариантов использования, классов и компонентов.
Аннотация: Занятие начинается с проблемы коммуникации в команде разработки и вводит UML как общий язык: расшифровка названия, краткая история и карта видов диаграмм. Центральная часть — нотация: класс и объект, интерфейс, компонент и узел, вариант использования и актор, пакет, заметка и связи между элементами. Разбираются две главные диаграммы — вариантов использования и классов — и дописанная к ним диаграмма компонентов. Элементы нотации закрепляются карточной игрой: сначала в режиме изучения, затем в режиме проверки на счёт. Продолжение — на занятии 7: диаграммы поведения.
Пререквизиты: Занятия 1–5 общего курса (постановка задачи, работа в команде). Знание какого-либо языка программирования не требуется: UML к языкам не привязан.
Мотивация: Между идеей и кодом лежит пропасть глубиной в десятки часов реализации: легко сбиться, отклониться от задумки, пойти на компромисс — и получить не то, что планировалось. Задача усложняется многократно, когда образ проекта нужно согласовать с командой, а отдельное удовольствие — согласовать его с заказчиком. Даже внутри команды аналитик, фронтендер и бэкендер часто называют одни вещи разными словами. Если бы все могли общаться на одном однозначном языке, процесс упростился бы радикально — и такой язык есть.

1. Что такое UML

UML (Unified Modeling Language, унифицированный язык моделирования) — язык графического описания для объектного моделирования в разработке программного обеспечения, применимый также к моделированию бизнес-процессов, системному проектированию и отображению организационных структур. По схемам UML участники команды — продакты, аналитики, программисты — «видят» на одном языке и понимают друг друга без погружения в код.

UML не привязан к языкам программирования: команда может писать на Java, Python или C# — безразлично. Более того, программирования может не быть вовсе: в бизнесе диаграммами UML изображают согласование договора или обработку жалобы, в производстве — последовательность создания продукта, в логистике — путь товара от склада до клиента.

Диаграмма последовательности действий клиента интернет-магазина: от выбора товара до получения заказа — Пример: последовательность действий клиента интернет-магазина

Расшифровка названия объясняет устройство языка:

U — Unified. Унифицированный: большой набор элементов покрывает множество задач анализа и проектирования; вторая версия происхождения — нотация объединила несколько разнородных нотаций, существовавших ранее.
M — Modeling. Диаграммы — это модели: наполненные информацией и связанные между собой графические объекты.
L — Language. UML — искусственный язык со словарём (графические символы), семантикой (смысл элементов) и синтаксисом (правила построения); заложена даже генерация кода из модели и модели из кода.

1.1. Откуда взялся UML

До середины 1990-х в объектно-ориентированном моделировании конкурировали несколько методологий — OMT Джеймса Рамбо, метод Гради Буча, OOSE Ивара Якобсона — с разными обозначениями, что мешало совместной работе и обучению. Втроём они объединили свои практики в компании Rational Software; результат — единая нотация UML, утверждённая консорциумом OMG как стандарт в 1997 году. UML 2.0 (2005) существенно расширил язык; актуальная версия — UML 2.5.1, спецификация доступна на сайте OMG (см. «Источники»).

Схема происхождения UML: методологии Буча, Рамбо и Якобсона объединяются в единый язык — Три методологии — один язык

2. Карта диаграмм UML

Диаграммы UML 2.x

Структурные

статика: классов, объектов, пакетов, компонентов, развёртывания, профилей, композитной структуры

Поведенческие

динамика: прецедентов, деятельности, состояний + взаимодействия (последовательности, коммуникации, синхронизации, обзора)

Структурные диаграммы описывают систему статически — из чего она состоит:

Диаграмма	Описание
Классов (Class)	Система как набор классов: свойства, методы, взаимосвязи.
Объектов (Object)	Экземпляр диаграммы классов с конкретными значениями свойств.
Пакетов (Package)	Взаимосвязи пакетов — групп классов, упрощающих сложную диаграмму.
Компонентов (Component)	Архитектура компонентов (сервисы, интерфейсы, приложения) и зависимости между ними.
Развёртывания (Deployment)	Система с точки зрения физического размещения.
Профилей (Profile)	Пользовательские стереотипы и ограничения моделей.
Композитной структуры	Внутреннее устройство классов и взаимодействие их элементов.

Поведенческие диаграммы описывают систему динамически — как она живёт во времени:

Диаграмма	Описание
Прецедентов (Use Case)	Функциональность, доступная акторам — внешним для системы сущностям. Употребляется и термин «диаграмма вариантов использования».
Деятельности (Activity)	Рабочий процесс внутри прецедента.
Состояний (State Machine)	Состояния объекта и правила переходов между ними.
Последовательности (Sequence)	Взаимодействие и обмен данными объектов в хронологическом порядке.
Коммуникации (Communication)	То же взаимодействие, но без раскрытия хронологии.
Синхронизации (Timing)	Поведение объектов на временной шкале.
Обзора взаимодействия	Высокоуровневый процесс, где каждый узел — другая диаграмма взаимодействия.

На этом занятии — три диаграммы «статики и требований»: вариантов использования, классов и компонентов; диаграммы поведения (деятельности, состояний, последовательности) — на занятии 7.

3. Нотация: из чего состоят диаграммы

Нотация — набор стандартных символов и правил для диаграмм: азбука, где вместо букв — фигуры, линии и стрелки. Все элементы делятся на три группы: графические элементы (прямоугольники классов, овалы вариантов использования), связи (линии и стрелки разных видов) и специальные обозначения (метки вроде «<<interface>>» или кратности «1..*»).

Типичная ошибка Читать элемент без учёта контекста. Один и тот же визуальный символ может означать разные вещи в зависимости от типа диаграммы — сначала определите, какая диаграмма перед вами, и только потом расшифровывайте её элементы.

3.1. Класс и объект

Класс — типовой объект или набор объектов с общими характеристиками и поведением, шаблон главной сущности системы: в онлайн-магазине это заказ, в онлайн-школе — студент. Изображается прямоугольником из трёх частей: имя, свойства (например, ID) и доступные действия — то, что объект умеет (заказ создаётся и выполняется, студент записывается и сдаёт задания).

Объект — конкретный экземпляр класса: выглядит так же, но имя подчёркнуто, а вместо заглушек — конкретные значения свойств.

3.2. Интерфейс

Интерфейс — список действий, которые может выполнять объект. Представьте монитор с подписью «нажми эту кнопку — включусь, этот кабель вставь в устройство»: монитору всё равно, подключат ли к нему компьютер или приставку, — важно как. Интерфейс описывает набор доступных операций, а не того, кто ими пользуется, — это позволяет проектировать гибкую архитектуру без привязки к реализации. На диаграмме рядом с элементом ставится пометка интерфейса, а от объекта к интерфейсу ведёт пунктирная стрелка реализации.

3.3. Компонент и узел

Компонент — крупная функциональная часть системы, отвечающая на вопрос «что делает система»: в сервисе доставки это, например, библиотека (хранение и обработка товаров) и каталог (управление списком доступного). Обозначается прямоугольником с двумя маленькими прямоугольниками на грани либо пометкой <<component>>; с другими элементами соединяется линией с кружком на конце.

Узел — ещё более крупный элемент, объединяющий компоненты. Если компонент — «что делает система», то узел — «где она это делает»: серверы, базы данных, физические и виртуальные устройства. Изображается кубом.

3.4. Вариант использования и актор

Вариант использования (use case, юзкейс) — конкретное применение системы: сделать заказ, оплатить, войти в личный кабинет, посмотреть историю, отменить заказ… Изображается овалом с названием внутри.

Актор — действующее лицо рядом с системой: в «спектакле» онлайн-магазина участвуют покупатель и курьер. Рисуется человечком-«палочкой» рядом с овалами юзкейсов, с которыми взаимодействует.

Почему актор — не класс и не объект? Потому что на диаграмме вариантов использования описывается, как работает система, а люди — внешние участники: они взаимодействуют с системой, но не являются её частью.

3.5. Пакет и заметка

Пакет — способ группировки элементов (объектов, классов, компонентов, узлов) в логические блоки; пакеты можно вкладывать друг в друга, как шкафчики под раковиной. Изображается прямоугольником с «язычком»-закладкой сверху.

Заметка — поясняющий текст к элементам диаграммы: прямоугольник с загнутым уголком, похожий на стикер.

3.6. Связи

Основные связи на диаграммах вариантов использования:

Ассоциация — актор взаимодействует с вариантом использования; сплошная линия. Покупатель ассоциирован с «Оформлением заказа».
Включение (<<include>>) — обязательное включение одного варианта в другой; пунктирная стрелка. «Оплата заказа» включается в «Оформление заказа» — без оплаты оформление не завершится.
Расширение (<<extend>>) — необязательное дополнение поведения; пунктирная стрелка от расширения к базовому варианту. «Регистрация» может расширять «Оформление заказа» — новый покупатель зарегистрируется, постоянный пропустит шаг.
Обобщение — наследование вариантов или акторов; сплошная линия с пустой треугольной стрелкой к базовому элементу. «Пользователь системы» обобщает «Покупателя» и «Администратора».

Игра с карточками · часть 1 — элементы нотации

Режим «изучение»: щёлкните карточку — на обороте название и назначение элемента. Режим «проверка»: показывается элемент и четыре варианта названия — набирайте серию правильных ответов. На занятии сыграйте против соседа: кто быстрее наберёт десять очков.

4. Диаграмма вариантов использования

Показывает, что пользователи могут делать в системе: зарегистрироваться, оформить заказ. Пользователи здесь — акторы, их действия — прецеденты. Диаграмма помогает понять, какие функции важны пользователю, и удобна для планирования требований — прецедент показывает, что делает система, а не как.

Диаграмма вариантов использования интернет-магазина: «оплатить» включается в «оформить заказ» обязательно, «зарегистрироваться» расширяет его при необходимости

Элемент	Описание	Изображение
Участник (actor)	Роль (человек) или система, взаимодействующая с прецедентами.
Прецедент (use case)	События, выполняемые системой и приводящие к наблюдаемому результату.
Ассоциация	Роль актора в конкретном прецеденте.
Расширение	Прецедент может расширяться поведением другого прецедента.
Обобщение	Один прецедент или актор — обобщение другого.
Включение	Прецедент включает поведение другого как обязательную часть.

5. Диаграмма классов

Самая популярная диаграмма UML: основные «кирпичики» системы — классы, их атрибуты, операции и связи, включая ограничения на связи. Используется и при проектировании кода, и в бизнес-моделировании.

Диаграмма классов магазина: закрашенный ромб — композиция (позиции не живут без заказа), пустой треугольник — наследование, числа у линий — кратности

Связь	Смысл	Изображение
Ассоциация	Отношение между экземплярами классов. Концы имеют кратность: у Товара может быть несколько Записей в накладной, но каждая Запись связана с одним Товаром. Связь можно именовать глаголом.
Агрегация	«Целое — часть»: ромб на стороне целого; части могут существовать отдельно от целого.
Композиция	Жёсткая агрегация: части не существуют отдельно и уничтожаются вместе с целым (дом — комнаты). Закрашенный ромб.
Наследование	«Общее — частное»: производный класс наследует структуру и поведение базового.

Типичная ошибка Путать агрегацию с композицией. Проверочный вопрос: переживёт ли «часть» уничтожение «целого»? Студент переживёт закрытие кружка — это агрегация; комната не переживёт снос дома — это композиция (закрашенный ромб).

6. Диаграмма компонентов

Третья диаграмма занятия отвечает за архитектуру: она показывает, из каких крупных частей собрана система и кто от кого зависит. Элементы — уже знакомые компоненты (раздел 3.3), а связывают их интерфейсы в «розеточной» нотации:

предоставляемый интерфейс — «леденец»: кружок на ножке; компонент предлагает эти операции всем желающим;
требуемый интерфейс — «гнездо»: полукруг на ножке; компоненту для работы нужны чужие операции;
совмещение леденца с гнездом означает соединение: один компонент пользуется услугами другого;
зависимость — пунктирная стрелка: изменение целевого компонента может затронуть зависящий.

Диаграмма компонентов игры: «леденцы» — предоставляемые интерфейсы, «гнёзда» — требуемые, пунктир — зависимость

Читается схема так: «Интерфейс игры» не знает, как устроен «Движок», — ему достаточно операций контракта IEngine; движок, в свою очередь, пользуется «Сохранениями» через ISave. Замените компонент «Сохранения» (файлы → облако), сохранив контракт, — остальная система не заметит подмены. Кто прошёл траекторию «Геймдев», узнает здесь идею инверсии зависимостей из конспекта A10 — диаграмма компонентов рисует её на уровне архитектуры.

Контрольные вопросы

Unified Modeling Language. Unified — унифицированный: покрывает множество задач и объединил ранее существовавшие нотации; Modeling — диаграммы являются моделями из связанных графических объектов; Language — искусственный язык со словарём, семантикой и синтаксисом.
Структурные описывают систему статически — из чего она состоит (классы, объекты, пакеты, компоненты, развёртывание); поведенческие — динамически, как она живёт во времени (прецеденты, деятельность, состояния, последовательности).
Имя класса; свойства (атрибуты — переменные характеристики вроде ID); доступные действия (операции/методы — что объект умеет делать).
Диаграмма вариантов использования описывает работу системы, а акторы — внешние участники: они взаимодействуют с системой, инициируют варианты использования, но её частью не являются.
Include — обязательное включение: базовый вариант не завершится без включаемого (оплата внутри оформления заказа). Extend — необязательное расширение поведения (регистрация может дополнить оформление заказа, но не обязана).
Обе — отношения «целое — часть» с ромбом у целого. При агрегации (пустой ромб) части живут отдельно от целого; при композиции (закрашенный ромб) части уничтожаются вместе с целым: дом и его комнаты.
Леденец (кружок на ножке) — предоставляемый интерфейс: операции, которые компонент предлагает другим. Гнездо (полукруг) — требуемый интерфейс: операции, которые компоненту нужны от других. Их совмещение — соединение компонентов через контракт.

Источники

Валитова, Д. Основы UML. Кому и зачем он нужен // Systems Education : [сайт]. — URL: https://systems.education/who-uses-uml (дата обращения: 08.07.2026).
UML-диаграммы: что это, какие бывают и как их использовать // Weeek : [сайт]. — URL: https://weeek.net/ru/blog/uml-diagrams (дата обращения: 08.07.2026).
OMG Unified Modeling Language : Specification 2.5.1 // Object Management Group : [сайт]. — URL: https://www.omg.org/spec/UML/2.5.1/PDF (дата обращения: 08.07.2026).
UML Component Diagrams // uml-diagrams.org : [сайт]. — URL: https://www.uml-diagrams.org/component-diagrams.html (дата обращения: 08.07.2026).